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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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All published ETSI deliverables shall include information which directs the reader to the above source of information. 
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1 Scope 

The present document contains general guidance on European ENUM trials and the specification for: 

• The format, contents and meaning of the information in the NAPTR records that are held by the ENUM Tier 2 
Nameserver providers and accessible by DNS. 

• The ways in which ENUM client software should interpret and act upon information obtained from NAPTR 
records. 

The present document is intended to enable interoperability between ENUM trials that are organized in different 
countries. This interoperability enables: 

• The same ENUM client software to work with NAPTR records generated by different national trials and this 
in turn will enable applications that use ENUM to access details of ENUM subscribers in more than one 
country without additional modifications. 

• Organizations to function as ENUM Registrars and ENUM Tier 2 Nameserver Provider in more than one 
national trial. 

The present document will therefore add economies of scope to the ENUM trials that will benefit ENUM subscribers, 
trial participants, application service providers and ENUM users. 

The present document is published as a Technical Specification (TS) at this stage as the contents are unproven. The 
intention is to update and upgrade the present document in the light of the results obtained from the trials. 

These requirements are therefore specified for the trial phase only, and as such impose no constraints on ENUM when 
implemented on a commercial basis following completion of the trial. 

Although the present document is focused towards European ENUM trials its use could facilitate interoperability with 
ENUM trials in other parts of the world. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE 1: The present document is based additionally on "Work in Progress" at the IETF, documented in Internet 
Drafts. This is especially valid for the syntax of the "ENUMservice" field in the NAPTR RR, which is 
based on the definitions in Internet Draft <draft-ietf-ENUM-rfc2916bis-05.txt>, which will supersede 
RFC 2916. Within the present document this Internet Draft is referenced as RFC 2916bis. 

[1] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[2] ETSI TS 102 05 1 : "ENUM Administration in Europe". 

[3] IETF RFC 1034: "Domain Names - Concepts and Facilities". 

[4] IETF RFC 1035: "Domain Names - Implementation and Specification". 

[5] IETF RFC 1 123: "Requirements for Internet Hosts — Application and Support". 
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[6] IETF RFC 1591: "Domain Name System Structure and Delegation" . 

[7] IETF RFC 1738: "Uniform Resource Locators (URL)". 

[8] IETF RFC 2181: "Clarifications to the DNS Specification", Updates: 1034, 1035, 1 123. 

[9] IETF RFC 2182: "Selection and Operation of Secondary DNS Servers". 

[10] IETF RFC 2255: "The LDAP URL Format". 

[11] IETF RFC 2368: "The mailto URL scheme". 

[12] IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 

[13] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[14] IETF RFC 2806: "URLs for Telephone Calls" . 

[15] IETF RFC 2818: "HTTP Over TLS". 

[16] IETF RFC 2916: "E.164 number and DNS". 

[17] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[18] IETF RFC 3401: "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive 

DDDS". 

[19] IETF RFC 3402: "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm". 

[20] IETF RFC 3403: "Dynamic Delegation Discovery System (DDDS). Part Three: The Domain 

Name System (DNS) Database". 

[21] IETF RFC 3405: "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA 

Assignment Procedures". 

NOTE 2: Also some of the above referenced URI Schemes are currently updated. 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 051 [2], with the exception of 
ENUM End User and ENUM Subscriber and the following apply: 

NOTE: The term ENUM End user is not used within the present document, ENUM User and ENUM Subscriber 
are defined as follows: 

ENUM Subscriber: assignee of an E.164 number who has agreed to insert its E.164 number in the ENUM DNS-based 
architecture and who requests population of an ENUM domain 

NOTE: The ENUM subscriber has full control over the provision and content of the NAPTR Resource Records in 
the ENUM Tier 2 Nameserver provider. The ENUM Subscriber is called ENUM End User in 
TS 102 051 [2]. 

ENUM User: person or entity who is querying the ENUM DNS-based architecture using an ENUM-enabled 
Application Client or an ENUM Client 

NOTE: The ENUM User may be aware only of the application and not of the use of ENUM by the application. 

In addition, the following terms and definitions apply: 

Application Client: function that provides a user access to the Application Server, e.g. a VoIP client or e-mail client 

Application Server: function provided by an Application Service Provider to communicate with the Application Client 
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ENUM Client: function that provides access to the DNS which will then return information in the form of NAPTR 
records 

NOTE: This could take several forms e.g. it may reside as client software on an intelligent terminal used directly 
by the ENUM User or be network based, provided upstream as part of the facilities offered by an 
Application Service Provider. 

ENUM Client Supplier: entity supplying the ENUM Client 

ENUM enabled Application Client: Application Client querying ENUM directly for NAPTR Resource Records 

ENUM enabled Application Server: Application Server that is using ENUM Clients as part of their application, 
e.g. an email server that translates phone numbers in the To:/RCPT fields into their ENUM stored mailto: values 

"ENUMservice": parameter held in the Service Field of a NAPTR Resource Record associated with the ENUM DDDS 
Application that indicates the class of functionality a given URl Scheme offers 

NOTE: According to RFC 2916bis an "ENUMservice" must be registered with the lANA via a description in an 
RFC. 

Naming Authority Pointer Resource Record (NAPTR): The Naming Authority Pointer Resource Record is specified 
in RFC 3403 [20] and a way to encode rule-sets in DNS. 

Resource Record: element within the Domain Names System (DNS) containing a data item associated with a domain 
name 

Uniform Resource Identifier (URI): compact string of characters for identifying an abstract or physical resource 
(e.g. an application) 

NOTE: An URI is used within a NAPTR Resource Record to point to a specific application. 

Uniform Resource Identifier (URI) Schemes: In the Uniform Resource Identifier (URI) definition (RFC 2396, 
RFC 1738) there is a field, called "scheme", to identify the type of resource. 

NOTE: URI Schemes are defined in RFCs and officially registered with the lANA 
(see http://www.iana.org/assignments/uri-schemes ). 

The following registered URI Schemes are used within the present document: 

ftp File Transfer Protocol RFC1738 [7] 

http Hypertext Transfer Protocol RFC 2616 [13] 

mailto Electronic mail address RFC 2368 [11] 

sip Session Initiation Protocol RFC 3261 [17] 

tel Telephone RFC 2806 [14] 

Idap Lightweight Directory Access Protocol RFC 2255 [10] 

https Hypertext Transfer Protocol Secure RFC 2818 [15] 

In addition, the not yet registered URI Schemes "h323" and "ENUM" are used. The "tel" URI Schemes is also currently 
undergoing modifications. For more information see the related Internet Drafts (work in progress). 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

H-NNN Any E. 164 number e.g. in the format H-12345678900 

CNAME Canonical Name DNS Resource Record 

DDDS Dynamic Delegation Discovery System 

DNAME DNS RR for non-terminal DNS Name Redirection 

DNS Domain Name System 

DNSSEC DNS SECurity extension 

EDNS Enhanced Domain Name System 

EMS Enhanced Message Service 

FAX Facsimile Service 

FTP File Transfer Protocol 
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H323 Protocol defined in ITU-Recommendation H.323 

lANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

IP Internet Protocol 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

LDAP Lightweight Directory Access Protocol 

MMS Multimedia Messaging Service 

NAPTR Naming Authority PoinTeR 

NICNAME Unique Identifier ("handle") pointing to personal information in WHOIS 

NRA National Regulatory Authority 

PC-Phones Phone Clients running on Personal Computers 

POSIX Portable Operating System Interface 

PSTN Public Switched Telephone Network 

RegExp Regular Expression 

RFC Request For Comment 

RIPE NCC Reseaux IP Europeens Network Control Center 

RR (DNS) Resource Record 

SIP Session Initiation Protocol 

SMS Short Message Service 

SW Software 

URI Uniform Resource Identifier 

VoIP Voice over IP 

WHOIS A tool (program) to look up domain names and related information in a database 



4 Introduction 

Following initial work on the national ENUM trials that are either being planned or taking place in several European 
countries, it has been recognized that additional benefits can be gained by facilitating interoperability of the various 
trials. The present document aims to assist those countries who wish to expand their trials on a pan-European basis. It 
proposes a minimum set of requirements for interoperability. 

ENUM Trial interoperability would enable benefits to be gained by sharing experience of different administrative, 
technical, operational and user aspects relating to the provision of ENUM capabilities between countries. Each country 
will have its own particular architectural, administrative, security and authentication requirements along with its 
particular implementation rules. Therefore linking the trials together will enable the various approaches to be evaluated 
on a broad basis. This approach would also widen the range of applications and services available to end users as it will 
enable them to access those provided by other trialists. 

Without commonality of some aspects especially as the format of the NAPTRs designed to support applications, 
attempts to link trials together are likely to result in difficulties when trying to access user information in more than one 
country. 

The results collected from pan-European trials should enable participants to gain valuable information and experience 
that will assist when commercial deployment is considered at a later stage. 

Involved parties are interested in carrying out trials for ENUM implementation in order to further the resolution of 
technical, administrative and operation issues that may define the rules for the commercial deployment in that country. 

In order not to presume any implementation solution, it is necessary that the minimum sets of requirements will not 
limit the freedom of individual trials and the possibility to take different approaches. 

The range of functional entities participating in a national trial depends on the choice of the administrative model in the 
country involved. The preferred model in a given country, in turn, depends on, among other things, the national 
arrangements for the management of domain names and E.164 numbers. TS 102 051 [2] outlines a number of options 
for the administrative model and explains the functions of these roles. Nonetheless, most of the roles (functional 
entities) listed are expected to be present in all European trials irrespective of the chosen administrative model: 

• ENUM Tier Registry 

• ENUM Tier 1 Registry 

• ENUM Tier 2 Nameserver Provider 
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ENUM Registrar 
Application Service Provider 
Authentication Agency 
ENUM Subscriber 
ENUM User 
For more general information on ENUM see TS 102 051 [2]. 



5 General objectives of ENUM trials within Europe 

Although the objectives for ENUM trials undertaken within any European country must remain totally a national 
matter, it should be recognized that additional benefits may be gained from shared experience if some of the general 
objectives are shared. Such experience can be further enhanced if different implementations are linked together. 

The following list of objectives identifies those that fall into this category and is recommended for trials that are linked 
together within Europe in order to share their ENUM experience: 

• Understanding the ENUM technology and its potential in providing new applications and services to 
customers. 

• Evaluating basic DNS infrastructure in relation to ENUM architecture models (for example ENUM Tier 1 
Registry, ENUM Registrar, ENUM Tier 2 Nameserver Provider, Authentication and Validation procedures). 

• Evaluate and refme the economic benefits and costs of introducing the ENUM capability. 

• Exchange of information related to processes e.g. provide process, change process, cessation process, dispute 
process. 

• Increase the overall size and thereby the benefits of European trials. 

• Provide feedback to the relevant standard bodies. 

• Provide feedback to NRA/Governments. 

Additionally the following list identifies aspects where additional benefits are likely to be gained, although their 
inclusion should be dependent upon each specific case and should remain a national issue: 

• Experience of registering the ENUM domain name related to the E. 164 number and the entry of the necessary 
data into DNS zone files. 

• Validation initiated by the ENUM Registrar (that the correct delegation is made to the ENUM Subscriber). 

• Gaining experience in provisioning ENUM delegation processes between ENUM Registrars and ENUM Tier 1 
Registries. 

• Exploring options for harmonized provisioning protocols across different countries as well as for unified 
validation processes. 

• Experience of sharing a common set of applications (e.g. VoIP) from a wider set of users. 
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ENUM trial interoperability 



This clause analyses the issues of interoperability and the constraints on the different roles of the parties involved in 
ENUM trials. 

6.1 Constraints in national trials 

The ENUM Subscriber in a national trial needs to have an E.164 number in the country concerned. Subscribers outside 
the countries running ENUM trials have no possibility of involvement as they will not have an E. 164 number that can 
be supported in the .el64.arpa part of DNS. Since DNS is open, the data relating to all ENUM subscribers is visible to 
any Application Service Provider or ENUM User in any country. 

The ENUM Registrar acts as an agent to input the ENUM Subscriber's ENUM domain name (E.164 number) into the 
ENUM Tier 1 Registry so that the Registry points to the correct ENUM Tier 2 Nameserver Provider in DNS. The 
ENUM Registrar needs to be appointed or recognized by the ENUM Tier 1 Registry. The ENUM Registrar may also 
have access to the ENUM Tier 2 nameserver to load, amend and delete NAPTR records in the format being used by the 
country concerned, or the ENUM Subscriber may load, amend and delete the NAPTR records directly with the 
nameserver themselves. Thus the ENUM Registrar's role is nationally specific, although the Registrar may be located 
anywhere. 

The ENUM Tier 2 Nameserver Provider holds the NAPTR records in the format being used by the country 
concerned. The ENUM Tier 1 Registry for the country concerned needs to point to that nameserver. The nameserver 
may be located anywhere. 

The ENUM Client Supplier is tied to the format of the NAPTR records for the national trial because their ENUM 
Clients need to be compatible with the NAPTR records. ENUM Clients may be embedded in Application Clients or 
Application Server or may be run as simple stand-alone applications. If the NAPTR records have different formats for 
different trials then different versions of the application would be needed to work with ENUM Subscribers in more than 
one country. 

The Application Service Provider may use ENUM Clients as part of their application. The Application Service 
Provider using ENUM may be located anywhere, even in a country that is not running an ENUM trial at all. An 
Application Service Provider not using ENUM is out of scope of this specification. 

The ENUM User may be located anywhere but, depending on the application, may need special Application Client 
software. 

Figure 1 shows the relationships involved for two different national trials and for a common model of the relationship 
between ENUM Tier 1 Registry, ENUM Registrar and ENUM Tier 2 Nameserver Provider. The ENUM Subscriber 
establishes their ENUM entry through the ENUM Registrar who loads this information into the NAPTR records held by 
the ENUM name server at Tier 2 level. (Alternatively the ENUM Subscriber may give this information directly to the 
ENUM Tier 2 Nameserver Provider). The ENUM Registrar then asks the ENUM Tier 1 Registry to create NS records 
for the ENUM Subscriber's ENUM domain name (associated with their assigned E.164 number) to point to the 
nameserver that holds the NAPTR records. An ENUM User uses an ENUM Client, either directly or as part of an 
ENUM enabled Application, to query the NAPTR records to find the information for the ENUM Subscriber with whom 
they wish to communicate. After obtaining the NAPTR records the ENUM User or their application may use this 
information to establish the communications between the ENUM User and the ENUM Subscriber. 

An ENUM User may either use the ENUM Client directly or use an Application Client. The Application Client in turn 
may either use the ENUM Client directly or forward the request to an Application Server, who may use an ENUM 
Client to query ENUM on behalf of the user. 
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Figure 1 : Relationships involved for ENUM Trial Interoperability 

Thus there are two constraints on interworking that can be removed by further action: 

• Recognition of an ENUM Registrar in more than one national trial. This would enable an ENUM Registrar to 
participate in multiple trials. It would not, however, allow the ENUM subscribers who are customers of the 
ENUM Registrar in Trial A to be ENUM Subscribers in a Trial B if their E. 164 number is in the national 
numbering plan for the country of Trial A. In other words, participation as an ENUM Subscriber is linked to 
the number range for which the ENUM Tier 1 Registry and ENUM Registrar are responsible. 

• Lack of standardization of the NAPTR records, which: 

Ties ENUM Clients to specific national trials. Standardization would enable applications with a single 
version of client software to work with all trials. 

Ties the operation of the name server on the Tier 2 level and its data entry and updating to specific 
national trials. Standardization would facilitate the use of the same name server in more than one trial. 

The present document focuses on the standardization of the NAPTR records because: 

• Recognition of the ENUM Registrar is a non-technical and national matter. In the longer term, consideration 
could be given to the potential benefits of harmonizing the interfaces between the ENUM Registrar and the 
ENUM Tier 1 Registry and ENUM Tier 2 Name Server. 

• Removing the constraint does not remove the limitation imposed by the E.164 number being linked to a 
particular national numbering plan. 
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6.2 Interoperability in ENUM trials 



Thus the main problem for interoperability arises from the lack of standardization of the "ENUMservice" field of the 
NAPTR records. If different formats and information are used in different trials, then the client software will work with 
only one national trial and this will limit the use of the applications or cause them to incur additional costs in running 
multiple versions of client software. 

The situation is summarized in the following table: 





Constraint on 
location 


Relationshiip to 
national trial 


Benefits of 

standardizing the 

NAPTR records 


Value of 

standardization of 

NAPTR records 


ENUM Subscriber 


Participation in a 
national trial is linked 
to having an E.164 
number in the number 
range covered by the 
trial and for national 
numbers this implies 
being located in the 
country of the trial 


Trial participant 


The data held in DNS 
is usable by more 
ENUM clients 


Medium 


ENUM Registrar 


Anywhere in the world 


Trial participant 

Needs technical 
compatibility with other 
trial participants 


If the registrar updates 
the NAPTR records 
then it can work with 
nameservers in more 
than one country and 
so can act as registrar 
for more than one trial 


Medium 


ENUM Tier 2 
Nameserver Provider 


Anywhere in the world 


Trial participant 

Needs technical 
compatibility with other 
trial participants 

Needs compatibility 
with the ENUM client 
software 


The nameserver can 
support trials in more 
than one country 


Medium 


ENUM Client Supplier 


Not relevant 


Not necessarily a trial 
participant 

Client software needs 
to be compatible with 
the ENUM Tier 2 
nameserver 


Client software can 
work without 
modifications in all trial 
countries 


High 


Application Service 
Provider that uses 
ENUM 


Anywhere in the world 


Not necessarily a trial 
participant 

Needs to use client 
software compatible 
with the ENUM Tier 2 
nameserver 


Application can be 
compatible with all 
trials with the same 
client software 


High 


ENUM User 


Anywhere in the world 


Not a trial participant 

Needs either: 
Client software 
compatible with the 
ENUM Tier 2 
nameserver, or 
software compatible 
with the application 


Can use the 
application with a 
larger group of ENUM 
subscribers 


Medium 
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6.3 Application recommendations to facilitate trial 
interoperability 

The following are proposed as minimum common application recommendations for ENUM trials: 



• 



To make trials most beneficial, it is envisaged to have ENUM Subscribers who are subscribed to e-mail, web 
and/or VoIP applications and who are provided with identifiers which may be used in the URI-Schemes listed 
in clause 9.4. 

It is further envisaged to have ENUM users who are provided with generic ENUM Clients or ENUM enabled 
Application Clients as described in clause 10. It is not necessary for ENUM Users to have support for all 
applications. 



7 Administrative requirements for interoperability of 

trials 

The following is set out as basic administrative requirements that have the objective of engendering a high level of 
confidence between different implementations of ENUM trials: 

For each trial: 

• national ENUM domains SHALL have been delegated from Tier level to Tier 1 level according to the 
interim procedures determined by the ITU-T. 

• operational and administrative processes SHALL be in place according to clause 11 of TS 1 02 05 1 [2] . 

• an open interface between ENUM Tier 1 Registry and ENUM Registrar 
NOTE 1: Interface likely to be different in different trials. 

• all ENUM domain names (associated with assigned E.164 numbers) inserted SHALL have been validated in 
accordance with the principles in TS 102 051 [2]. 

• ability to insert as a minimum geographic numbers in ENUM. 

• WHOIS type capability: 

NOTE 2: WHOIS is a tool that is used to look up domain names and related information in a database. It is used 
within gTLDs and ccTLDs Registries to look up e.g. second-level domain information. The primary use 
is to look up the availability of a domain name. The additional information provides e.g. domain name 
holder, administrative contact, technical contact, zone contact, billing contact, nameservers used and 
unique identifiers pointing to personal information (NICNAME). 

Within ENUM (el64.arpa) a WHOIS type capability SHALL be used to provide similar information for delegated 
full ENUM domain names (associated with assigned E.164 numbers) at the ENUM Tier 1 Registry level. This is 
considered as required during the trials and shall be harmonized. Whether all or parts of this information conforms 
with the elements stated in the note above or is made publicly available is a national matter. 

• Adequate data protection safeguards are essential in the interoperating trials. In countries that implement EU 
legislation, trials SHALL implement procedures that ensure compliance with national laws corresponding to 
the EU Data Protection Directives. In other countries, trials SHOULD implement procedures that are 
consistent with the EU Data Protection Directives except where this conflicts with national laws 

NOTE 3: All ENUM subscribers within the trials must be made aware that once the contents of their registration 
are inserted within ENUM, they may be publicly available. 

• all ENUM trials SHALL define policy objectives and SHALL adhere to the procedures defined for the 
national ENUM trial. 
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8 DNS requirements for interoperability of trials 

The following are proposed as minimum common DNS requirements for ENUM trials: 

• For interoperability of European ENUM Trials, the global DNS server hierarchy SHALL be used, so they 
should use public DNS servers within the normal hierarchy; these are ENUM Trials using delegations by 
RIPE/NCC according to the interim procedures defined by ITU- and according to TS 102 051 [2] and the 
present document. 

• ENUM DNS Nameserver operation SHALL be implemented according to RFC 1034 [3], RFC 1 123 [5], 
RFC 1591 [6], RFC 2181 [8] and RFC 2182 [9]. 

• ENUM delegations at the ENUM Tier 1 Registry point to the ENUM Tier 2 name servers which must be 
authoritative for that zone. 

• Name servers MUST not run insecure name server software and SHALL be protected against security 
penetration attacks. 

• DNS Servers used in ENUM Trials are not required to support TCP requests 

• To ensure a basic level of conformance, adherence to the following points is recommended: 

Name servers should have sufficient capacity to support reasonably high query rates. 

Name servers should be protected against denial of service attacks. 

Appropriate logging and audit trails should be established for name servers. 

Name servers should be installed in co-located facilities with 24x7 monitoring, backup power supplies, 
etc. 

9 Harmonization of the "ENUMservice" field in the 
NAPTR Records 

9.1 Background to minimum requirements for NAPTR use 

As described and explained in annex A, there is not a single "ENUMservice" field yet defined according to RFC 
2916bis in an RFC and registered with I AN A. Even RFC 2916bis is still an Internet draft and not an RFC. 

Therefore an ENUM trial needs to make assumptions about the "ENUMservice" fields and "URI Schemes" used with a 
given ENUM application. If different ENUM trials are making independent assumptions, it may happen that different 
and eventually incompatible assumptions are made. This may result in incompatible ENUM trial implementations. 

To avoid this, a consistent set of "ENUMservices" fields are defined within the present document. Any ENUM trial and 
ENUM Client SW implementing this set of "ENUMservices" fields is guarantied to be compatible to any other ENUM 
trial and ENUM Client SW also implementing this set. 

The "ENUMservice" fields defined in the present document will be forwarded to the IETF ENUM WG as Internet 
drafts containing registration templates according to RFC 2916bis to be discussed and approved as RFCs for 
registration of the "ENUMservice" fields with lANA. 

A Registration Template needs to contain the following information. 

ENUMservice Name: 

Type(s): 

Subtype(s): 

URI Scheme(s): 

Functional Specification: 

Security considerations: 

Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 
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Author: 

Any other information that the author deems interesting: 

Since the Internet Drafts forwarded to the IETF may be modified during the following discussion, there is no guarantee 
that the "ENUMservices" finally registered with lANA are identical with the "ENUMservices" in the European trials as 
specified within the present document. 

On the other hand, the experience gathered during the trials may also lead to modifications of the "ENUMservices" 
defined for the usage during the trials. 

Consideration may be given to updating the present document after a certain time period if necessary and to align it to 
the "ENUMservice" fields finally registered RFC with lANA, either to be used in a second phase of ENUM trials or 
finally for a commercial application. 

9.2 General conditions 

The minimum requirements for interoperability are: 

ENUM clients SHALL assume that the DNS Infrastructure for ENUM is available in the domain el64.arpa. 

The ENUM domain names associated with any given E. 164 number SHALL be accessible from any client 
using the standard technical mechanisms specified in RFC 2916bis and RFC 1035 [4]. 

The ENUM Subscribers participating in the ENUM Trial SHALL provide at least one URI (e.g. e-mail, web), 
using any Application Service Provider. 

The ENUM client SHALL be able to query the domain evaluated for recordtype NAPTR. 

NAPTR records SHALL be formatted according to RFC 3403 [20]/RFC 2916bis and the "ENUMservice" field 
SHALL be used as defined in the present document. 

The NAPTR Resource Records SHALL be understandable (and be capable of being processed) by any ENUM 
Client. This has several aspects: 

The entity publishing the Resource Record and the entity querying the Resource Record SHALL have a 
common understanding of the meaning stored in that Resource Record. 

To achieve this, within the ENUM trials a common (basic) set of "ENUMservices" is agreed that MAY 
be expected within the service field of an ENUM NAPTR Record. The "ENUMservices" define also a 
common (basic) set of URI Schemes. 

The list of "ENUMservices" and "URI Schemes" used is limited to the set defined in clause 9.4. 

This does NOT mean that every ENUM Client SHALL support all of the "ENUMservice" fields that are 
in this set, but instead that it SHALL recognize the meaning of these values and common defined 
behaviour (see note below) SHALL be provided for "ENUMservices" and URI Schemes which are not 
recognized by the ENUM Clients. 

Note that this list is a requirement for interoperation. However, it is perfectly valid for other applications to be 
tested within individual Trials and thus for Resource Records indicating these applications to exist within an 
ENUM domain that is part of such a Trial. As the content of the ENUM domain is physically accessible from 
anywhere, an ENUM Client may receive Resource Records containing application indicators that it does not 
support or recognize, complex RegExp fields, or even non-terminal NAPTRs. 

Clients should be designed to expect receipt of such records. They should have a defined behaviour when 
encountering Resource Records that they cannot understand, a defined behaviour when encountering Resource 
Records that indicate service features that they cannot support, and defined behaviour when encountering 
non-terminal NAPTRs or problems. It is important that an ENUM Client should be able to recognize a 
complex RegExp field, and should not attempt to use the partially evaluated result if it does not support fully 
regular expression processing. 

An ENUM client SHALL be able to convert an entered E. 164 number in the format H-NNN according to the 
rules given in RFC 2916bis clause 2 into a domain name ending in el64.arpa. 
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• The DNS Resolver used by the ENUM Client will process any CNAME or DNAME Resource Records 
transparently. 



9.3 Format and processing of NAPTR records 



• The NAPTR records SHALL be in the format as defined in RFC 3403 [20] and contain the following fields: 
order, preference, flags, services, regexp and replacement (see annex A). 

• For interoperability of the ENUM trials, the following simplifications are recommended: 

The ENUM clients MAY ignore all NAPTR records except those with Flag "U". The flag field value 
should always be "U" and never blank, so the NAPTR result need not to be re-submitted and loops are 
easily avoided. It follows from this that the replacement field will always be empty. 

The Order field for all NAPTRs within a single ENUM domain SHALL be set to the same value 
(e.g. 10). 

The Preference field MAY be used by the ENUM Subscriber as a recommendation to the order in which 
the contacts should be presented to the ENUM user. The ENUM client MAY order the list of NAPTRs 
using the Preference field; however it is not required to do so. 

The regular expression field SHALL use the "!" character as a delimiter. 

As a minimum, an ENUM Client need not be able to process NAPTRs that include RegExp fields that 
have consequent parts that are dependent on the matching part (i.e. where a string of form "\1" is 
included), and this part is not just a literal string holding the URL If unable to process RegExp fields in 
this format, it should nevertheless be able to detect the presence of such a pattern and reject the NAPTR, 
and MUST not attempt to use this string. 

The RegExp field is in two parts; a matching part followed by a consequent part. Unless unavoidable, the 
matching part SHOULD include only a fully matching pattern, with the consequent part holding a 
complete replacement, without re-using matched patterns. These can be considered as a command to 
"throw away the input string and replace by the literal string held in the consequent part". In the format 
of the regular expression field, this would appear as "!'^.*$!full-uri!" (where "full-uri" holds the target 
URI string). 

An ENUM client is not required to support queries including the EDNS "extended length" option. 

NOTE: Setting EDNS "extended length" option flag with a length parameter will transmit a response using a 
packet of up to this length. Not including the EDNS "extended length" option flag will result in the 
default 500 octet limit being applied. If the server has more data than will fit into this, it will set the 
truncated flag in the response. On receipt of this truncated response, the client may re-submit the query 
using TCP. If TCP transport is supported by the ENUM DNS Servers, then the full response will be 
returned using this method. 

Note, however, that where DNSSEC is used, this may preclude use of ENUM clients that cannot support 
"extended length" queries as the data for DNSSEC secured responses often requires extended length 

messages. 

To support ENUM Clients that do not support use of the EDNS "extended length" option in conjunction 
with ENUM DNS Servers that do not provide service using TCP, the space available for returned 
resource data should be limited to ca. 500 octets. 

As a result, the maximum number of NAPTRs populated in any queried subdomain should be limited to 
fit into this space - this equates to a limit of approximately 5 NAPTRs per ENUM domain, unless 
DNSSEC is used. 

Any ENUM Client should expect, however, to receive truncated responses and should act accordingly. It 
should also expect the DNS Server holding the ENUM data to not provide service using TCP. 

ENUM Clients should check for presence of more than one "+" and understand this to mean that there is 
more than one "ENUMservice" defined for this record. 
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It is suggested that a NAPTR with more than one "ENUMservice" type should be displayed as a number 
of values, each supporting one "ENUMservice" field. In effect, the NAPTR is converted in the Client to 
a number of "NAPTRs", each with a single "ENUMservice". 

Note that if the NAPTR includes more than one "ENUMservice" field, then if the URI-scheme differs 
between the ENUMservices, or the URI scheme is different from that shown in the Regular Expression 
field, then the NAPTR is incorrect and MUST be rejected by the client. 

Note that there is an exception to this - if a NAPTR has an ENUMservice sip or ENUMservice h323, 
then as these are tied to the URI scheme, there cannot be a NAPTR with, for example, E2U+sip+h323, as 
this would imply that the NAPTR contained more than one URI. 

9.4 "ENUMservices" and associated URI Schemes 
9.4.1 IVIinimum set of "ENUIVIservices" 

All "ENUMservice" fields SHALL be in the format "type: subtype" as defined in RFC 2916bis, with the exception of 
the "ENUMservices" "sip" and "h323", which have only a "type". 

Note that the "subtype" shown in the following list is always a copy of the URI scheme held in the NAPTR (duplicated 
from the consequent part of the RegExp field). 

9.4.1 .1 "ENUMservices" for Interactive Media-stream Exchange 

This group of "ENUMservice" fields indicates that the associated resource can be used for interactive (media stream 
exchange) calls. 

Voice services 

• voice: sip 

• voice:h323 

• voice:tel 

These "ENUMservices" indicate that the resource identified by the associated URI is capable of being contacted to 
provide a communication session during which interactive media streams carrying voice data can be exchanged. 

Video services 

• video: sip 

• video:h323 

• video :tel 

These "ENUMservices" indicate that the resource identified by the associated URI is capable of being contacted to 
provide a communication session during which interactive media streams carrying video data can be exchanged. 

9.4.1 .2 "ENUMservices" for Discrete (non-session related) Messages 

This group of "ENUMservices" is intended to indicate that the associated resource is capable of receiving a discrete 
(non-session related) message or document. This group may be selected by a querying client if they want to deliver a 
message (such as a Fax) to a correspondent. 

• email :mailto 

This "ENUMservice" indicates that a remote resource can be addressed by the associated URI in order to send 
emails. 
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fax:tel 



This "ENUMservice" indicates that the resource identified by the associated URI is capable of being contacted 
to provide a communication session during which facsimile documents can be sent. 

• sms:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Short Message Service (SMS). 

• ems:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Extended Message Service (EMS). 

• mms:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Multimedia Message Service (MMS). 

9.4.1 .3 "ENUMservices" for Information Source 

This group of "ENUMservices" indicates that the associated resource can act as a source for information. It acts as the 
"opposite" of the "ENUMservices" associated with message sending, in that the latter indicates a source for data whilst 
the former indicates a sink for data. 

• web:http 

• web:https 

These "ENUMservices" indicate that the remote resource identified by the associated URI is capable of 
providing documents when contacted using web protocols; in short, it acts as a web server for the data 
addressed by the associated URI. 

• ft:ftp 

This "ENUMservice" implies that the associated URI identifies a remote resource that provides a file service 
from which an addressed document (or file listing) can be retrieved. 

9.4.1 .4 "ENUMservices" for Service Resolution Services 

This group of "ENUMservices" is used where the ENUM subscriber wants to use a specialized "Service Resolution 
Service" above and beyond ENUM. It can be used where the services available depend on factors that cannot be 
covered in the global ENUM system; for example, the services "advertised" may depend on the person asking, and so 
requires authentication to be performed before any detailed information is returned. 

• sip 

• h323 

NOTE: These are the only services where the protocol part is not used (see above). 

For more information on these "ENUMservices" see <draft-peterson-ENUM-sip-OO.txt> and 
<draft-levin-ENUM-h323-00.txt>. 

9.4.1 .5 "ENUMservices" for Session-oriented Message Exchanges 

This group of "ENUMservices" indicates that the remote resource is capable of engaging in chat sessions 
(i.e. session-oriented message exchanges). It differs from the "ENUMservices" in clause 9.4.1.2 (discrete messages) in 
that the latter group implies a session-oriented message exchange, whilst the former group implies a discrete message 
can be sent to the resource at this contact address. 

• tp:tel 
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This "ENUMservice" indicates that a remote resource addressed by the associated URI is capable of involvement in a 
textphone session. This is a group of systems that use the PSTN to transfer character data between compatible 
terminals. These are commonly used by users who have hearing impairment. 

• im:sip 

This "ENUMservice" indicates that the remote resource is capable of engaging in a session-oriented "instant message" 
exchange. 

9.4.1 .6 "ENUMservices" for Instant Information Display - Announcement 

This group of "ENUMservices" indicates that an item of instant information from the ENUM Subscriber is to be 
presented by the ENUM Client to the ENUM User. 

• ann:sip 

• ann:h323 

• ann:tel 

The above "ENUMservices" shall point to recorded announcements 

• ann:http 

• ann:ftp 

These "ENUMservices" shall point to a webpage containing at least text and voice data. 

As announcements including both text and sound are especially important for people with hearing and visual 
impairments, it is proposed to use a reference to resources holding both kinds of data where possible, either via a web 
page with embedded sound links or a directory (accessed via FTP) that includes both kinds of announcements. 

NOTE: This group is intended to trigger automatic execution. There are significant risks involved in this, due to 
unsolicited onward actions. Clients may wish to consider disabling this feature by default. Further study 
is required during the trials. 

9.4.1 .7 "ENUMservice" for Redirection 

This "ENUMservice" is a special case in that it includes all other "ENUMservices" within it. The goal is to provide a 
default "ENUMservice". This may be used to indicate that the "ENUMservices" supported with a NAPTR are not 
specified in any more detail. In effect, the ENUM Subscriber is asserting that this NAPTR supports ALL 
"ENUMservices". However, in practice it means that further processing (by evaluating the regexp and so constructing 
the associated URI) is needed before the end system can be sure whether to discard the record or not. 

• alkENUM 

NOTE 1: This "ENUMservice" may either be used by the ENUM Subscriber to forward the ENUM user to another 
subdomain holding his "real" NAPTRs or by the Tier 1 Registry to redirect from one subtree to another. 

NOTE 2: The "ENUM:" URI scheme as defined in <draft-brandner-ENUM-uri-OLtxt> has the same syntax as the" 
tel:" URI (defined in <draft-antti-rfc2806bis-08.txt>) without any parameters and only allowing E.164 
numbers. Developers should consider that instead of the "ENUM:" URI also a "tel:" URI with the same 
restrictions may be used. 

EXAMPLE: $ORIGIN 2.2.2.3.4.el64.arpa. 

* IN NAPTR 10 10 "u" "E2U+all:ENUM" "!'^+43222(.*)$!ENUM:+431\l!" . 

This example shows the redirection of a whole subtree within the domain 3.4.el64.arpa in case of 
an area code split. Any number within the area code +43 222 xxxxxxx not having a resource 
record associated with it is redirected to the new area code +43 1 xxxxxxx. Of course any full 
E.164 Number can simply be redirected with e.g.: 

$ORIGIN0.L8.7.8.0.L8.7.8.0.L8.7.8.el64.arpa. 
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INNAPTR 10 10 "u" "E2U+all:ENUM" "!'^.*$!ENUM:+436644204100!" . 

9.4.2 Additional "ENUMservices" 

These "ENUMservices" require further study prior to implementation. 

9.4.2.1 "ENUMservices" for Location Information 

This "ENUMservice" indicates that the associated resource can act as a source for location information. It is proposed to 
provide this information in Geography Markup Language (GML). 

• loc:http 

9.4.2.2 "ENUMservices" for Public Key Information 

These "ENUMservices" indicate that the associated resource can act as a source for public key information. 

• key:ldap 

• key:http 

10 Processing of retrieved information by ENUIVI Clients 
10.1 Generic ENUIVI Clients 

The generic ENUM Clients SHALL query the DNS for all NAPTR records in the given domain. 

All generic ENUM Clients SHALL recognize as a minimum the "ENUMservices" and URls in clause 9.4.1: 

• This does not imply that an application supporting the given "ENUMservice" field and URl-scheme is 
available and may be launched. 

• Recognition of these "ENUMservice" fields allows the client to use this knowledge to present appropriate 
options. 

The ENUM Clients SHALL present "ENUMservices" options derived from the retrieved NAPTR Resource Records. 
(e.g. for "E2U+voice:sip" sip:user@work.net the client may present a button with "Make a voice call"). 

Exception: 

In case of "ENUMservice" "all" the E.164 number given in the URI Scheme SHALL be used to make another ENUM 
query and the NAPTRs retrieved should be presented as described above. 

All ENUM Clients SHALL therefore first look for "ENUMservice" "all:ENUM". If a NAPTR with this 
"ENUMservice" is found, an additional query SHALL be launched for the ENUM domain given by the "ENUM:" URI 
Scheme. To prevent endless loops, the client SHALL make only a maximum of 5 such redirections. 

If an "ENUMservice" "ann:http" is found, the Application Client SHALL indicate this fact. 

An ENUM Client SHALL display any "ENUMservice" "ann:http" found if this is compatible with the capabilities of 
the ENUM User's terminal. ENUM Clients MAY also act on "ann:sip", "ann:h323" or "ann:ter' where found, if 
compatible with the ENUM User's terminal capabilities. 

Regarding the presentation of the "ENUMservices" and the URI Schemes it may be feasible to provide the means for 
the ENUM User to launch an appropriate Application Client. 

The ENUM Clients may either select the appropriate application by themselves or provide a provisioning interface 
where the user may link specific Application Clients to a given "type: subtype" combination (e.g. voice:h323 will launch 
an H323 Application Client, voice:tel will launch either a SIP or H323 Application Client, as defined by the user). 
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Whether unsupported "ENUMservices" are presented at all or presented in a different way (e.g. "greyed-out/fade 
away") may be determined by the ENUM Client or even by the ENUM User. 

1 0.2 ENUM enabled Application Clients 

All available Application Clients MAY be launched by a generic ENUM Client. 

The Application Clients also MAY be able to query ENUM directly. These clients are called ENUM enabled 
Application Clients. 

ENUM enabled Application Clients need only support the "ENUMservices" they are designed for. 

This is done by entering an E. 164 Number in the format +NNN into the "target" field. Application Clients that 
understand E.164 Numbers in the first place (e.g. PC -Phones) MAY need to be configured explicitly by the user to 
make an ENUM query first. 

All ENUM enabled Apphcation Chents SHALL first look for "ENUMservice" "alkENUM". If a NAPTR with this 
"ENUMservice" is found, an additional query SHALL be launched for the ENUM domain given by the "ENUM:" URI 
Scheme. To prevent endless loops, the client SHALL make only a maximum of 5 such redirections. 

If an "ENUMservice" "ann:http" is found, the ENUM enabled Application Client SHALL indicate this fact. 

An ENUM enabled Application Client SHALL display any "ENUMservice" "ann:http" found if this is compatible with 
the capabilities of the ENUM User's terminal. ENUM enabled Application Clients MAY also play "ann:sip", 
"ann:h323" or "annitel" found if compatible with the ENUM User's terminal capabilities. 

Then the ENUM enabled Application Clients SHALL look for NAPTRs containing any "ENUMservice" related to this 
ENUM enabled Application Client as described above. If no NAPTR containing a usable "ENUMservice" is found, the 
ENUM enabled Application Client should indicate this fact to the ENUM User. This indication shall be different from 
the indication that the domain has not been found. 

The specific minimum behaviour of the specific ENUM enabled Application Clients for each application is described in 
next clause 10.3. 

Further capabilities are up to the specific ENUM enabled Application Client. 

1 0.3 Examples of specific ENUIVI enabled Application Clients 

In addition to the processing described in 10.2, the following applies to specific ENUM enabled Application Clients. 

1 0.3.1 ENUIVI enabled SIP Client 

An ENUM enabled SIP Client should look primarily for "ENUMservice" "sip". If the "ENUMservice" "sip" is found, 
the client should establish a connection to the SIP URI given and start negotiating the service. 

If no NAPTR with "ENUMservice" "sip" is found, the ENUM enabled SIP CHent should look for "ENUMservice" 
"voice:sip" and if available, should establish a voice connection to the given SIP URI. 

Depending on the service provided by the SIP application, the ENUM enabled SIP Client may also look for 
"ENUMservices" "voice:tel", "video:sip" and "video:tel", then for "ENUMservices" "email: mail to", "fax:tel" and 
"im:sip". 

1 0.3.2 ENUM enabled H323 Client 

An ENUM enabled H323 cUent should look primarily for "ENUMservice" "h323". If the "ENUMservice" "h323" is 
found, the client should establish a connection to the h323 URI given and start negotiating the service. 

If no NAPTR with "ENUMservice" "h323" is found, the ENUM enabled H323 Client should look for "ENUMservice" 
"voice:h323" and if available, should establish a voice connection to the given H323 URI. 

Depending on the service provided by the H323 application, the ENUM enabled H323 client may also look for 
"ENUMservices" "voice:tel", "video:h323" and "videoitel", then for "ENUMservices" "email:mailto" and "fax:tel". 
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1 0.3.3 ENUM enabled Email Client 

An ENUM enabled Email Client SHALL look for "ENUMservice" " email :mailto". If this "ENUMservice" is found, the 
ENUM enabled Email Client shall establish a connection to the given mailto URL 

If the ENUM enabled Email Client is capable of dealing with public keys and the "ENUMservice" "key:ldap" is found 
in addition, the ENUM enabled Email Client may indicate that an encrypted mail may be sent. 

1 0.3.4 ENUM enabled Web Browser 

An ENUM enabled Web Browser SHALL look for "ENUMservices" "web:http" or "web:https" and display the given 
web-page given within the URL If the Web Browser is capable of processing the FTP protocol, it MAY also look for 
"ENUMservice" "ft:ftp". 

1 0.3.5 ENUM enabled FTP Client 

An ENUM enabled FTP Client SHALL look for "ENUMservice" "ft:ftp" and retrieve the file given within the URL 

1 0.3.6 ENUM enabled FAX Client 

An ENUM enabled FAX Client SHALL look for "ENUMservice" "faxitel" and send the FAX message to the E.164 
number given in the URL 

1 0.3.7 ENUM enabled SMS Client 

An ENUM enabled SMS Chent SHALL look for "ENUMservice" "smsitel" and send an SMS message to the E.164 
number given in the URL In addition, the SMS Client SHALL look for "emsitel" and "mmsitel", as SMS forms a subset 
of these services, and so an SMS may be delivered using them. The ENUM enabled SMS Client may either be an 
application having web-access to an SMS centre, or an IP-enabled (e.g. GPRS) mobile phone. 

1 0.3.8 ENUM enabled Location Client 

An ENUM enabled Location CHent SHALL look for "ENUMservices" "loc:ldap" or "loc:http" and retrieve location 
information. The location information may e.g. be given in Geographic Mark-up Language (GML). The application 
client may either be a stand-alone application displaying the location information to the user or an embedded 
application using the location information for further processing (e.g. driving instructions, directions). 
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Annex A (informative): 

Background to NAPTR Resource Records 

This annex gives a background to "NAPTR" Resource Records and the "ENUMservice" field and is mainly derived 
directly from the referenced RFCs. 

The ENUM System as defined in Internet Draft <draft-ietf-ENUM-rfc2916bis-05.txt>, which will supersede 
RFC 2916 [16], discusses the use of the DNS for identifying available services connected to an E.164 number. Through 
the transformation of E.164 numbers into DNS names and the use of existing DNS services, especially the NAPTR 
records as defined in RFC 3403 [20], one can look up what services are available for the related E.164 number. 

ENUM is about a specific usage of "NAPTR" Resource Records within the Domain Names System (DNS), as 
explained within the Dynamic Delegation Discovery System (DDDS). The DDDS is specified in a series of documents 
(RFC 3401 [18] to RFC 3405 [21]). 

The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, in order to 
support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored 
within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. 

An introduction and overview to the DDDS is given in "Dynamic Delegation Discovery System (DDDS) Part One: The 
Comprehensive DDDS" (RFC 3401 [18]). In order to fully understand any document in this series it should be noted 
that all other documents should also be read. 

"Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" 
(RFC 3403 [20]) describes the way in which the Domain Name System (DNS) is used as a data store for the Rules that 
allow a DDDS Application to function. It does not specify any particular application or usage scenario. The present 
document also obsoletes RFC 2915. ENUM is a particular "application" and described in RFC 2916bis. 

The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified in RFC 3403 [20] was originally 
produced by the IETF URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a 
Uniform Resource Identifiers (URI) <RFC 2396> [12] could be decomposed in such a way that they could be changed 
and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by 
a client program to rewrite a string into a domain name. 

Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to 
be encoded in a rather small DNS packet. They are a combination of a POSIX Extended Regular Expression and a 
replacement string similar to Unix sed-style substitution expression, for the syntax see RFC 3402 [19]. 

In the case where two "Applications" may use the same database (which is actually the case with DNS and the ENUM 
and URI Resolution Applications), there is a chance of collision between rules where two NAPTR records appear in the 
same domain but they apply to more than one Application. Different ways exist to avoid collisions, the way chosen in 
ENUM is to use different values in the Services field (see below), so a record from another Application will be ignored 
since it does not apply to the Service fields in question. 

The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35. 
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The packet format for the NAPTR record is as follows: 

111111 
0123456789012345 
+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
I ORDER I 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
I PREFERENCE I 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ FLAGS / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ SERVICES / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ REGEXP / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ REPLACEMENT / 

/ / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 

<character-string> and <domain-name> as used here are defined in RFC 1035 [4]. 

"ORDER" field 

A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately 
represent the ordered list of Rules. Since no ordered lists are used within the ENUM Field trials, this field is not 
applicable (see also clause 9.3). 

"PREFERENCE" field 

Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the 
DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order 
values SHOULD be processed, low numbers being processed before high numbers (this field is applicable in the 
ENUM field trials, see clause 9.3). 

"FLAGS" field 

A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. 
Flags are single characters from the set A-Z and 0-9. The case of the alphabetic characters is not significant. The field 
can be empty. It is up to the "Application" specifying how it is using this Database to define the Flags in this field. It 
must define which ones are terminal and which ones are not. Therefore RFC 2916bis specifies that at this time only one 
flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [12]. For more 
information see clause 9.3. 

"SERVICES" field 

A <character-string> that specifies the Service Parameters applicable to this delegation path. It is up to the 
"Application" Specification to specify the values found in this field. 

Therefore RFC 2916bis defines this field as follows: 

Service Parameters for this "Application" (ENUM) take the following form and are found in the Service field of the 
NAPTR record. 

service_field = "E2U" 1 *(servicespec) 
servicespec = "+" ENUMservice 
ENUMservice = type 0*(subtypespec) 
subtypespec = ":" subtype 
type = 1*32( ALPHA / DIGIT) 
subtype = 1 *32(ALPHA / DIGIT) 

In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) 
followed by 1 or more "ENUMservices" which indicate what class of functionality a given end point offers. Each 
"ENUMservice" is indicated by an initial "+" character. 
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An "ENUMservice" MUST be registered with the lANA via a description in an RFC. "ENUMservices" specifications 
contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be 
returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the 
"ENUMservice" and URI schemes or protocols. The mapping, if any, has to be made explicit in the present document 
for the "ENUMservice" itself. A registration of a specific "type" also have to specify the "subtypes" allowed. 

A registered "ENUMservice" must be able to function as a selection mechanism when choosing one NAPTR resource 
record from another. That means that the registration MUST specify what is expected when using that very NAPTR 
record, and the URI which is the outcome of the use of it. 

Specifically, a registered "ENUMservice" MUST specify the URI scheme(s) that may be used for the "ENUMservice". 

Since there is not a single "ENUMservice" registered with lANA yet, the definition of this field is one of the main 
purposes of the present document. 

"REGEXP" field 

A <character-string> containing a substitution expression that is applied to the "original string" held by the client in 
order to construct the next domain name to lookup. See the DDDS Algorithm specification (RFC 3402 [19]) for the 
syntax of this field. In case of the ENUM Trials, the regexp always produces an URI, for more information see 
clause 9.3. 

"REPLACEMENT" field 

This field is not used within ENUM Trials. 

RFC 2916bis defines in addition how to get the "original string" mentioned above and how to access the database (for 
more information on the terms used see the DDDS RFCs): 

• that the Application Unique String (AUS) for ENUM is a fully qualified E. 164 number minus any non-digit 
characters except for the "+" character which appears at the beginning of the number. 

• that the First Well Known Rule for ENUM is the identity rule, which gives the original string. 

• that the output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 
"absoluteURI" production in the Collected ABNF found in RFC 2396 [12]. 

• that at present only one DDDS Database is specified for ENUM. "Dynamic Delegation Discovery System 
(DDDS) Part Three: The DNS Database" (RFC 3403 [20]) specifies a DDDS Database that uses the NAPTR 
DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. 

The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters 
except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name 
according to this algorithm: 

1) Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the 
Key "H-4689761234". This step would simply remove the leading "+", producing "4689761234". 

2) Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 

3) Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 

4) Append the string ".el64.arpa" to the end. Example: 4.3. 2.1.6.7. 9. 8.6.4.el64.arpa 

This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, 
produces new keys in the form of domain-names from the DNS. 
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